Virtual machine operating systems are well known today. For example, an IBM z/VM operating system creates a virtual machine environment, as follows. A base operating system (also known as a Control Program, “CP” or hypervisor) of the IBM z/VM virtual machine operating system logically divides physical resources, i.e. CPU time, RAM, storage, etc. of a real computer to form different virtual machines. Thus, each virtual machine has a share of processor time, RAM, storage, etc. to form a virtual computer and execute is own “guest” operating system and applications. The guest operating system and applications operate (i.e. use their virtual machine's share of processor time, RAM, storage, etc.) in the respective virtual machine as if they were executing in their own dedicated real computer.
Programs in different virtual machines can also communicate with each other through a hypervisor. According to one communication technique, the communication between the different virtual machines via the hypervisor may comprise messages using proprietary protocols such as Inter-User Communication Vehicle (“IUCV”) or Virtual Machine Control Facility (“VMCF”). These communication protocols exhibit the following common properties:                a) The source virtual machine first writes the message into the source's virtual address space.        b) The source virtual machine identifies the target virtual machine by name.        c) The hypervisor generates an interrupt to notify the target virtual machine of the incoming message. The interrupt invokes interrupt handling in the target virtual machine.        d) In response to the target virtual machine agreeing to receive the message, the hypervisor copies the message from the source's virtual address space to the target virtual machine's virtual address space.        
The following is a more detailed description of IUCV. IUCV is a point-to-point protocol to transfer data from one source virtual machine to one target virtual machine. To communicate via IUCV protocol, a source virtual machine first prepares to receive communications by invoking the hypervisor to declare an IUCV buffer for interrupts and incoming messages. To initiate communication, a source virtual machine then invokes the hypervisor indicating the identity of the intended target virtual machine for the communication. If the target has agreed to communicate by having declared an IUCV buffer for interrupts and incoming messages, the hypervisor generates an interrupt to the target virtual machine and provides the target virtual machine with a communication path id for this connection. Assuming the target virtual machine agrees to communicate with the source virtual machine, the target virtual machine invokes the hypervisor to accept the communication path. The hypervisor then interrupts the source virtual machine and provides the source virtual machine with its communication path id for this connection. To send the actual message, the source virtual machine invokes the hypervisor indicating the previously obtained path id and the actual message to be sent. In response, the hypervisor uses the path id to identify the target virtual machine and generates an interrupt to the target virtual machine. The target virtual machine responds to the interrupt by invoking the hypervisor to receive the actual message. The hypervisor then copies the data from the source virtual machine's virtual address space to the target virtual machine's virtual address space and generates an interrupt to the source virtual machine indicating that the data has been transferred. The program in the target virtual machine can then read the message from the target virtual machine's address space.
The following is a more detailed description of VMCF. VMCF is a protocol to transfer data from a source virtual machine to a target virtual machine. To communicate using VMCF, a source virtual machine first prepares to receive communications by invoking the hypervisor to authorize its use of VMCF and declare an area of its storage as a VMCF interruption buffer. To send an actual message, the source virtual machine constructs the message to be transmitted and invokes the hypervisor to deliver it to a designated target virtual machine, which the source virtual machine identifies by name. If the target virtual machine has also authorized its use of VMCF, the hypervisor generates a VMCF interrupt to the target virtual machine. The target virtual machine responds to the interrupt by invoking the hypervisor to receive the actual message. The hypervisor then copies the data from the source virtual machine's virtual address space to the target virtual machine's virtual address space and generates an interrupt to the source virtual machine indicating that the data has been transferred. The program in the target virtual machine can then read the message from the target virtual machine's address space.
Thus, whereas IUCV is a connection-oriented protocol in which messages are sent back and forth on an established path, VMCF is a connectionless protocol in which each message is independently addressed to the target virtual machine by name. The term “incoming interaction” is used herein to refer to a request to communicate with a target virtual machine, for example, by a connection request in the case of a connection-oriented protocol like IUCV, or an individual message in the case of a connectionless protocol like VMCF. For further details on the IUCV and VMCF protocols, see z/VM: CP Programming Services, IBM order number SC24-6084-02, which document is hereby incorporated by reference as part of the present disclosure.
As long as there is only one configuration per virtual machine, the incoming interactions under IUCV and VMCF can be resolved unambiguously to that single configuration. However, according to U.S. Pat. No. 4,660,144 to Walsh, a single virtual machine can have two (or more) different configurations, all instantiated concurrently and alternately or simultaneously active (dispatchable). Each of the configurations specifies a number of virtual processors, an amount of virtual machine memory, addresses and types of virtual devices, and an associated operating system name or boot device. Each configuration defines an environment to execute an operating system and applications. One configuration may be called a “Principal” or main configuration, and another configuration may be called an “Adjunct” or secondary configuration. When the hypervisor generates an interrupt for an interaction initiated by a configuration of a source virtual machine, there are different known ways for the hypervisor to determine which of a target virtual machine's configurations is to receive and process the interrupt and associated interaction. This determination is necessitated because interactions such as VMCF messages and IUCV connection requests are addressed to a virtual machine, not to a particular configuration that is instantiated within that virtual machine. The interrupt handler associated with each configuration is the one provided by the operating system running in the configuration. It was known to use a predetermined one of the configurations for all incoming interactions and associated interrupts. A problem with this approach is that the other configuration is precluded from handling any incoming interactions and associated interrupts. It was also known to use, for a current interrupt, the configuration that was currently active for the virtual machine. A problem with this approach is that the configuration which is currently active is dynamic and cannot reliably be determined in advance by the virtual machine that initiated the interaction to be the appropriate one to receive the interrupt.
An object of the present invention is to determine which configuration of a target virtual machine is appropriate to process an incoming interaction initiated from a configuration of another virtual machine.